1. Field of the invention
This invention is related to database management systems, computer systems, and computing application systems in which lambda-definable (effectively computable) functions including discrete data are stored and managed. These systems are used to manage various informations in businesses, in scientific researches, in computer systems, and in human livings.
2. Description of the prior art
A traditional database is a collection of related discrete data. It is physically supported by a software called a database management system (DBMS), and physical storages that permanently store the data. The DBMS provides an interface between the data and the rest of the world (users). It shows to users how the stored data is related or organized, and then allows users to insert new data into the database, to update, delete and retrieve data in the database.
The way of showing the discrete data to users is dominated by the DBMS, and are the key criterion to evaluate the quality of the database, or specifically the quality of the DBMS. A hierarchical DBMS exhibits stored data in a hierarchical fashion in the sense that the stored data is organized in a hierarchical structure. A network DBMSs exhibits stored data in a network fashion in the sense that the stored data is organized in a network structure. A relational DBMS exhibits stored data in a set of tables. And a object-oriented DBMS exhibits stored data in the way similar to a network DBMSs, but with additional concepts such as object super/sub classes and inheritances.
Hierarchical and network DBMSs are no longer popular due to their limitations in database applications and due to other reasons. Relational database management systems are the most popular and effective in the modern industry. Although relational DBMSs have many disadvantages in database applications, there hasn't had other DBMSs that could take over the leading position of relational DBMSs. Object-oriented database managements systems were introduced under criticisms against relational database management systems. However, they don't provide significant improvement enough in taking over the leading position.
The way of showing the discrete data in a database immediately affects the cost of the development and the maintenance of a database application that uses the DBMS. FIG. 1 illustrates a typical system architecture of a database application. Through analyzing each component of the database application, the disadvantages of the traditional DBMSs are itemized later.
In FIG. 1, Database Application 20 is a typical database application system in which Relational Database 24 is the core of Database Application 20. Relational Database 24 physically comprises Relational DBMS 25 and storages 26 and 27, and it logically shows to users that the stored data 27 is organized in n-ary relations (tables). Therefore Relational Database 24 actually is viewed as an accessible relational database with the support of its physical components. Stored Data 27 is the physical storage that keeps the database 24 permanently alive; and Data Schema 26 is a piece of storage permanently storing the application-dependent data schema that defines partial rules of the database 24. In Relational DBMS 25, there are two functional modules--Relational Constraints 28a and Query Interpreter 29a. Relational Constraints 28a is the software that provides the interface for users to change the data schema 26 and the stored data 27. It guarantees that data accesses from users remain the integrity of the database 24 in the sense that each change to the database 24 obeys the rules specified in the Data Schema 26 and the rules of the regular relational databases. Another functional module in Relational DBMS 25 is Query Interpreter 29a that accepts queries in SQL, translates them into file-access statements and returns the answers. Relational Database 24 is accessed through message channel 33 and 34. Although SQL should be more accurately refer to a query language that interfaces with Query Interpreter 29a, SQL here (and in industry also) refers to the overall language that includes a Database Definition Language (DDL) through the message channel 34 and a Data Manipulating Language (DML) through the message channel 33 that further includes the query language. The data schema 26 is entered through the message channel 34 by systems administrators. Stored Data 27 is accessed through the message channel 33.
User Interface 21 is the software supporting a display in text, in tabular form, or in graph through which users interact with Relational Database 24. Procedure Calls 30 is a set of procedure calls that represent the functional specifications of data access requests. With the traditional database 24, Database Application 20 normally requires more components. Application Software 23 is the software developed specifically for the database application 20, and it is the implementations of the specifications in Procedure Calls 30. It translates a procedure call into a sequence of operations in Relational DBMS 25. Application Software 23 functionally comprises the module of Application Constraints 28b, and the module of Application Query Interpreter 29b. Application Constraints 28b enforces additional rules in changing the state of Relational Database 24, which is a make-up of both Relational Constraints 28a and Data Schema 26. Application Query Interpreter 29b implements the query specifications from procedure calls 30 that accomplishes the implications of the query specifications to Relational Database 24. Data Interpreter 22 is a software for the data communication of the database application 20 with the rest of world. It translates data from a language to another. Message channels 32 and 35 are in a language convenient to the database application, and defined by the database application. Channel 31 is a language commonly used by industry for data communication.
The disadvantages of the traditional database management system 24 are summarized in the following:
1. Low computing automation. For a typical data application 20 which uses a relational DBMS 25, the application-dependent software, Application Software 23 above Relational DBMS 25, is needed to satisfy high-level specification from User Interface 21. The necessity of the application-dependent software 23 stems from the following two circumstances. For more detailed theoretical discussion about data models and database queries, see "Foundations of Databases", S. Abiteboul, R. Hull, V. Vianu, Addison-Wesley Publishing Company, 1995: PA0 Relational DBMS 25 is not able directly to interface with User Interface 21 (either through a set of procedure calls in the module 30, or any other high-level specifications). The reason is that tabular structures (relations) used by the database 24 are too simple to manage complex objects (data); or equivalently, the reason is that SQL is not able to support the high-level specifications that users need. Therefore, Database Application 20 needs Application Constraints module 28b constructed from host programming languages that further controls data accesses to Relational Database 24. Application Constraints 28b is a makeup of both Relational Constraints 28a and Data Schema 26. PA0 B. To support queries from users, the Application Query Interpreter 29b in Application Software 23 is also required. First of all, Database Application 20 usually avoid using join or union operations in SQL. The reason is that the join or union operations are very expensive in terms of performance (measurement of computing time). Therefore, user-guided data searching embedded in Application Query Interpreter 29b is provided to replace the join and union operations. Secondly, SQL is not able to express queries involving least fixpoints (similar to "While" statement in a host programming language) that are common in a typical database application. Although a theoretical query language Datalog supports least fixpoint queries, it is too expensive to be used in practice. Thirdly, the sets as the responses to queries in SQL or Datalog miss certain application information that User Interface 21 needs. For example in FIG. 9, no matter how the directed graph is managed by a relational database, SQL or Datalog is not able to return &lt;A, B, C, D&gt; in the sequence as the answer of the query "print a sequence of nodes that form a directed path from A to D". Thus, a host programming language must be used to support queries beyond the capability of SQL. Application Query Interpreter 29b is a make-up of SQL Interpreter 29a. PA0 2. Expense of developing Data Interpreter 22. To communicate with other computer systems, Database Application 20 needs additional module--Data Interpreter 22 developed in host programming languages. In a distributed computing environment, a common language is needed for sub-systems to talk to each other. A modern relational DBMS 25 normally supports a SQL-based language for data communication. However, the SQL-based languages are normally not accepted as efficient languages for data communication. There are many standards defined in data communication that use hierarchical-based structures for carrying data. However hierarchical-based structures are not effective in storing data in databases. This requires a language interpreter--Data Interpreter 22 between database application 20 and other systems. Since Data Interpreter 22 interacts with Application Software 23, Data Interpreter 22 is also application-dependent, and it is developed per database application. PA0 3. Poor system reliability and performance of the database application. Developing Application Software 23 and Data Interpreter 22 not only significantly increases the cost of the development of Database Application 20, but it also degrades the system reliability and performance of the database application. It is obvious that Application Software 23 and Data Interpreter 22 developed in a short period of time normally provides less reliability than a general-purpose product such as Relational DBMS 25 does. Similarly, due to computing overhead involving in many layers without clean functional partitioning (from Stored Data 27 to User Interface 21), the overall performance of the database application 20 is degraded. PA0 4. Disability of managing large volume of data. Due to the flat structures of Relational Database 24, relational DBMSs have unacceptable system performances once the size of the databases become large. For more detailed discussion, see "Future Trends in Database Systems" by M. Stonebraker and L. Rowe, IEEE transactions of Knowledge and Data Engineering, Vol. 1., No. 1, March, 1989, pp 33-44. PA0 5. Disability of integrating with other computer application systems. Different common languages are used for different database applications. As a result, different distributed database applications cannot talk to each other. Further, database applications that normally store and maintain discrete data cannot talk to other computing systems that deal with mathematically expressible functions. For example, a database user through User Interface 21 is not able to submit queries like: what is the square of a integer? PA0 6. Not easy to learn. Database Application 20 is physically supported by Relational DBMS 25 and Application Software 23 that don't provide clean functional partitioning in terms of system architecture. And further Database Application 20 is built with many different languages such as SQL, a host programming language, and a common communication language. These make Database Application 20 difficult to be understood and to be developed. PA0 1. High computing automation. As mentioned above, systems administrators are able to define all constraints of the database application 40 through channel 54; LDF DBMS 45 is able to take "complex data" from User Interface 41, and to store it in Stored Data 47; the common language with lambda calculus is used for all the message channels 51, 53 and 54, and the only application-dependent software is Functional Specifications 50. This indicates that the automation degree of developing database application is increased significantly. PA0 2. No data translation is needed. Since a functional language is for data communication with the rest of th world, the application-dependent software for data translation is not needed. PA0 3. High system reliability and performance. The entire Database Application 40 only consists of LDF DBMS 45, Functional Specifications 50, and User Interface 41. DBMS 45 is a general-purpose product from other vendors with high reliability. Functional Specification 50 is the only application-dependent software in a high-level language. Therefore, the system reliability is significantly improved. And the system performance also is improved because computing overhead is not existed any more due to clean functional partitioning in Database Application 40. Although it is known that a general functional programming language implies low system performance, the functional programming language used in message channels 51, 53, and 54 is supported by a set of built-in procedures that stem from the special structure of the database in LDF Database 44. The set of built-in procedures are efficient in accessing LDF Database 44, and support most of queries from users. Further more, the special structure of the database in LDF Database 44 will also significantly benefit the overall system performance of the functional programming language for data accesses. For more information, see the section "Detailed Description". PA0 4. Ability to store large volume of data. Due to the special structure of the database in LDF Database 44, the Stored Data 47 can be stored in hierarchical structures. That makes data distribution easier. PA0 5. Ability of integrating with other systems. Because a functional programming language in message channel 51 is used for data communication, it can be accepted as the common language for data communication that is able to specify any functions under the class of effectively computable functions. With the functional programming language as the common language, Database Application 40 can communicate with other systems without the need of data translation. An analog of a distributed database system is a distributed file system in which each sub-system can be easily "plugged" into the distributed file system without any additional software development. PA0 6. Easy to learn. A participant of a database application development has less things to learn: applications, and the database technologies of LDF DBMSs.
A) To create, delete, or modify a data instance that has dependent relationship with other data, users want to specify the operation at high level in the sense that multiple operations in Relational DBMS 25 are triggered by the high-level specification implied in a procedure call. For instance, if the database application 20 is a CAD related database application, users only specifies through User Interface 21 that a car is to be created that triggers a procedure call in the module 30. Then the creation of the car implies the creation of thousands of parts inside the car in the database 24. If Database Application 20 is for a school administration, users through User Interface 21 only specifies that a student quits from the school that triggers a procedure call in the module 30. Then the student's quitting implies the removal of all the records related to the student from Database 24, such as the name in the registration office; the student's study records in several classes; and the name in a sports club.
Because Application Software 23 needs to be constructed per Database Application 20, the degree of computing automation is low. It is well-known that developing Application Software 23 is the most expensive effort in the development life cycle of Database Application 20.